Determining a Device Posture Using a Device Posture Token

ABSTRACT

Disclosed are various approaches for generating a device posture token corresponding to a client device. The device posture token can be used by a verification computing device to determine whether the client device complies with the security policies of a particular facility.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims the benefit of U.S.patent application Ser. No. 16/733,625, entitled “DETERMINING A DEVICEPOSTURE USING A DEVICE POSTURE TOKEN,” and filed Jan. 3, 2020, which isa continuation of U.S. Pat. No. 10,530,813, entitled “DETERMINING DEVICEPOSTURE USING A DEVICE POSTURE TOKEN,” and issued Jan. 7, 2020, which ishereby incorporated by reference in its entirety.

BACKGROUND

In today's environment, smartphones and other devices are becoming moreand more ubiquitous and more essential to users, both for personal andenterprise uses. Many users prefer not to go any period of time withouttheir devices in their possession. Client devices issued by anenterprise can be managed by a management service that provides theability to remotely manage or administer devices that are enrolled withthe management service as a managed device. For example, devices can beenrolled with a remotely executed management service using applicationprogramming interfaces (APIs) or other capabilities that are embeddedwithin the operating system of the device. A management component canalso be installed on a client device so the device can be locallymanaged by the management component and remotely managed by themanagement service.

Certain facilities, such as government facilities or sensitive corporatefacilities, can impose policies that restrict what devices can bephysically brought into the facility. For example, a government facilitywhere highly classified or sensitive information is housed mightrestrict devices that have cameras from brought into the facility. Asanother example, a facility might restrict devices having certainapplications from being brought into a facility. To comply with suchrestrictions, the device can be configured to adhere to therestrictions, either through a manual configuration of the device by theuser or through management of the device by a management service and/ormanagement component. However, when a device complies with therestrictions or requirements set forth by such a facility, there waspreviously no convenient way for security personnel of the facility tovalidate that the device is compliant when the user wishes to enter thefacility.

BRIEF DESCRIPTION OF THE DRAWINGS

Many aspects of the present disclosure can be better understood withreference to the following drawings. The components in the drawings arenot necessarily to scale, with emphasis instead being placed uponclearly illustrating the principles of the disclosure. Moreover, in thedrawings, like reference numerals designate corresponding partsthroughout the several views.

FIG. 1 is a schematic block diagram depicting an example implementationaccording to various examples of the disclosure.

FIGS. 2-3 are examples of the device token application according toexamples of the disclosure.

FIGS. 4-5 are examples of the device token application and verificationapplication according to examples of the disclosure.

FIGS. 6-8 are flowcharts that illustrate functionality according toexamples of the disclosure.

DETAILED DESCRIPTION

Disclosed are examples of a system that creates a device posture tokenthat can allow for verification of a device's compliance with one ormore compliance rules. In many corporate, government, or other types offacilities, computing devices such as smartphones, tablets, or othercomputing devices are often banned from entering the building. In manycases, these outright bans exist because security personnel cannot (orcannot easily) verify whether the devices of visitors comply with thepolicies that an organization owning or operating the facility has inplace for security reasons. In one example, the enterprise owning oroperating the facility might require that any device sensor capable ofcapturing confidential information be disabled for such device to bepermitted to enter the facility. For instance, the facility mightrequire that a camera and a microphone of the device be disabled.

More particularly, the above described technical problem predominantlyoccur in two scenarios. First, the technical problems can occur in ascenario where an employee of an enterprise wishes to bring their deviceinto a facility owned or operated by such enterprise. In this case,security personnel would not likely be authorized to access anadministrative console of a management service that manages theemployee's device (“facility management service”), as that permissionwould likely be restricted to Information Technology personnel.Nevertheless, were security personnel to be authorized, the securitypersonnel could only determine compliance of the particular employee'sdevice through a tedious process using the facility management service.In particular, the security personnel would need to authenticate to gainaccess to the facility management service, query to find a device recordassociated with the particular employee's device, and determine whetherthere is any indication that the device is out of compliance with thesecurity policies required for the device to be permitted to be broughtinto the facility. This process is burdensome and would causesignificant delays in processing of individuals at security checkpoints.

Second, further technical problems may occur in a scenario where anemployee of a first enterprise wishes to bring their client device intoa facility owned or operated by a second enterprise, such as when theemployee is a contractor or visitor (“foreigner”). In this case, theforeigner's client device would likely be managed by a managementservice associated with the first enterprise (“foreign managementservice”), and security personnel of the second enterprise would notlikely capable of determining whether the foreigner's client device iscompliant with the security policies. In particular, it is unlikely thatthe security personnel of the second enterprise would be authorized toaccess the foreign management service to identify state informationassociated with the foreigner's client device, precluding the securitypersonnel from determining compliance. Consequently, a technicalsolution is needed to provide security personnel with a mechanism todetermine the compliance of a device before it is allowed to enter thefacility (both for devices associated with the enterprise owning oroperating the facility and devices that are associated with visitors).

Accordingly, examples of the disclosure include systems and methods todetermine whether a user's device is compliant with compliance policiesby way of a device posture token. In one scenario, a device posturetoken can be generated by a management service with which a clientdevice is enrolled. In one example, the device posture token canidentify one or more compliance rules that comprise security policiesand the status of the client device with respect to those rules. Inanother example, the device posture token can describe the state of theclient device, which can then be compared to security policies todetermine the status of the client device with respect to such. In yetanother example, the device posture token can comprise a credentialconfigured to provide access to a network-driven application programminginterface (API) command of the management service, which can cause themanagement service to transmit, to a device from which the API commandwas received, one or more of the security policies, the compliancestatus of the client device with respect to such, or state informationdescribing the client device. In any case, the management service canprovide the device posture token to the client device by transmitting itover a network (e.g., through a device management messaging protocol).

The client device can then provide the device posture token to averification computing device (e.g., a hand-held device configured toreceive a device posture token), such as one operated by securitypersonnel of a facility upon entrance to the facility. For instance, theclient device can display a visual representation of the device posturetoken (e.g., quick response (QR) code, two-dimensional barcode, otherrepresentation of an alphanumeric number) on a display of the clientdevice and the verification device can use a camera sensor of theverification device to capture the visual representation and therebyaccess the associated device posture token. Alternatively, the clientdevice can provide the device posture token to the verification deviceby transmitting it over a network (e.g., NFC, Bluetooth, Wi-Fi,cellular).

Using the device posture token, the verification device can determinewhether the client device complies with its organization's securitypolicies and, thus, whether the security personnel should permit theclient device to be taken into the facility or whether the securitypersonnel should prohibit the client device from being taken into thefacility. In one example, the verification device can determine whetherthe device posture token indicates whether the client device iscompliant with the security policies. In another example, theverification device can identify state information associated with theclient device from the device posture token and can compare it to thesecurity policies to determine whether the client device is compliantwith such. In a further example, the verification device can identify acredential and/or a network-driven API command from the device posturetoken, which the verification device can use to cause the managementservice to provide the verification device with (e.g., transmit to it)one or more of the security policies, the compliance status of theclient device with respect to such, or the state information associatedwith the client device that can be used by the verification device todetermine compliance status of the client device as described above. Inany case, the verification device can use the device posture token toprovide security personnel with the compliance status of the clientdevice, which the security personnel can use to base their decision topermit or deny admittance of the client device into the facility.

Additionally, a trusted computing relationship can be establishedbetween the management service associated with the client device and theverification device to provide the verification device with a mechanismto verify the authenticity of the device posture token (and the contentsthereof). Establishing such a trusted computing relationship can involveproviding the verification device with a public key associated with themanagement service associated with the client device. To preventsecurity breaches, administrator authorization may be required for thetrusted computing relationship to be established. That is, before thepublic key associated with the management service associated with theclient device is provided to or accepted by a verification device, anadministrator of one or more of the management service associated withthe client device or the verification device may need to authorize theestablishment of the trusted computing relationship. Once theverification device has access to the public key associated with themanagement service associated with the client device, the verificationdevice can use the public key to decrypt the device posture token.Further, the verification device can use the decrypted device posturetoken to determine whether the client device associated with deviceposture token is in compliance with the organization's securitypolicies.

FIG. 1 illustrates an example of a networked environment 100 accordingto examples of the disclosure. In the depicted network environment 100,an enterprise computing environment 103 is in communication with atleast one client device 106 and at least one verification computingdevice 107 (“verification device”) over a network 119.

The network 119 includes the Internet, intranets, extranets, wide areanetworks (WANs), local area networks (LANs), wired networks, wirelessnetworks, other suitable networks, or any combination of two or moresuch networks. The networks can include satellite networks, cablenetworks, Ethernet networks, and other types of networks.

The enterprise computing environment 103 can be a computing environmentthat is operated by an enterprise, such as a business or otherorganization. The enterprise computing environment 103 includes acomputing device, such as a server computer, that provides computingcapabilities. Alternatively, the enterprise computing environment 103can employ multiple computing devices that are arranged in one or moreserver banks or computer banks. In one example, the computing devicescan be located in a single installation. In another example, thecomputing devices for the enterprise computing environment 103 can bedistributed among multiple different geographical locations. In onecase, the enterprise computing environment 103 includes multiplecomputing devices that together can form a hosted computing resource ora grid computing resource. Additionally, the enterprise computingenvironment 103 can operate as an elastic computing resource where theallotted capacity of computing-related resources, such as processingresources, network resources, and storage resources, can vary over time.In other examples, the enterprise computing environment 103 can includeor be operated as one or more virtualized computer instances that can beexecuted to perform the functionality that is described herein.

Various applications or other functionality can be executed in theenterprise computing environment 103. Also, various data can be storedin a data store 112 that can be accessible to the enterprise computingenvironment 103. The data store 112 can be representative of a pluralityof data stores 112. The data stored in the data store 112 can beassociated with the operation of the various applications or functionalentities described below.

The components executed on the enterprise computing environment 103 caninclude a management service 116, a device token generator 120, andother applications, services, processes, systems, engines, orfunctionality not discussed in detail herein. The management service 116can be executed in the enterprise computing environment 103 to monitorand oversee the operation of one or more client devices 106 byadministrators. In some examples, the management service 116 canrepresent one or more processes or applications executed by anenterprise mobility management (EMM) provider that facilitatesadministration of client devices 106 of an enterprise that are enrolledwith the EMM provider. To this end, the operating system and applicationecosystem associated with the client device 106 can provide various APIsand services that allow client devices 106 to be enrolled as manageddevices with the management service 116. The management service 116 caninitiate installation of applications as managed applications. Themanagement service 116 can also initiate installation of configurationprofiles that can be accessed by certain applications installed on aclient device 106.

The management service 116 can include a management console that canallow administrators to manage client devices 106 that are enrolled withthe management service 116. User interfaces can allow an administratorto define policies for a user account or client devices 106 associatedwith an enterprise environment. The user interfaces can also include,for example, presentations of statistics or other information regardingthe client devices 106 that can be managed by the management service116.

The enterprise computing environment 103 can also execute a device tokengenerator 120. The device token generator 120 can generate a deviceposture token 151 that can include one or more of a representation ofone or more compliance rules that comprise the security policies of anenterprise, a representation of the compliance status of a client device106, or other hardware and software properties of the client device 106(i.e., state information). The device token generator 120 can encode thecompliance status of the client device 106 and other metadata about theclient device 106 into data structure or other alphanumeric encodingthat can be encoded within a QR code or other data representation. Insome examples, the device posture token 151 can be provided by thedevice token generator 120 or management service 116 directly to theclient device 106. The device posture token 151 can then be provided bythe client device 106 to the verification device 107, which can verifywhether the client device 106 complies with the security policies of theorganization associated with the verification device 107, such as theadmittance policies to a particular facility.

The data stored in the data store 112 can include device records 123,user data 124, compliance rules 125, and potentially other data. Devicerecords 123 can include correspond to client devices 106 that areenrolled as managed devices with the management service 116. A devicerecord 123 can include various security settings selected forenforcement on a client device 106 that is enrolled with the managementservice 116. Accordingly, a device record 123 can include a deviceidentifier associated with a device, such as the client device 106, oneor more device certificates, a compliance status 129, and other data. Insome examples, a device record 123 can also identify a user associatedwith a particular client device 106. The compliance status 129 canindicate whether a particular client device 106 is in compliance withone or more compliance rules 125.

More specifically, the device record 123 can include one or more of:data describing the identity, type and components of the client device106; data describing the state of the client device 106; data describingorganizational groups to which the client device 106 belongs; datadescribing compliance rules 125 with which the client device 106 mustcomply; data describing management policies that specify if, when andhow the client device 106 is permitted to function; and data describinga command queue associated with the client device 106.

For example, data describing the identity, type and components of theclient device 106 can specify at least one of more of: a uniqueidentifier associated with the client device 106 (e.g., identifierissued by a manufacturer of the client device or the management service116), a device type of the client device (e.g., a smartphone, a tabletcomputing, a laptop computer, a desktop computer, a server computer, ora virtualized instance of any of such computer types), and varioussoftware and hardware components of the client device 106 (e.g.,operating system [or kernel or bios] type and version, processor typeand speed, memory type and size, network interface types, various I/Ocomponent types such as camera, touchscreen, keyboard, mouse, printer).More particularly, a device record 123 associated with a client device106 comprising a network connection television can specify that theclient device 106 is a device type of phone, that the client device 106has an active connection to the Internet, and that the client device 106has a camera enabled.

Next, data describing the state of the client device 106 can specify,for instance, various settings that are applied to the client device106, various applications that are installed on or being executed by theclient device 106, and various files that are installed on or areaccessible to the client device 106. Additionally, the data describingthe state of the client device 106 can specify information related tothe management of the client device 106, such as the last time theclient device 106 provided its state information to the managementservice 116, whether the client device 106 is in a state of compliancewith any applicable compliance rules 125, and whether any remedialactions have been (or are to be) taken as a result of a noncompliancewith any applicable compliance rules 125. Also being related to themanagement of the client device 106, the data describing organizationalgroups to which the client device 106 belongs can, for example, includeany organizational groups of which the client device 106 is a member (byvirtue of a static hard coded relationship between the client device 106and an organizational group, or by virtue of a dynamic evaluation of amembership condition associated with an organizational group, asdescribed later herein).

Further, the device record 123 can include data describing a commandqueue associated with the client device 106. For example, the managementservice 113 can maintain a command queue of commands that are designatedfor execution against the client device 106. As described herein, aclient device 106 can be provisioned by the management service 116 bycausing resources to be installed or stored on the client device 106. Toimplement such process, the management service 116 can store a commandrelated to provisioning in the command queue. Additionally, themanagement service 116 can store a command related to a remedial actionassociated with a compliance rule 125 in the command queue, in the eventthat it is determined that a rule condition associated with thecompliance rule 125 has occurred. Whether a provisioning command or acommand related to a remedial action is stored in the command queue, theclient device 106 can retrieve commands stored in its command queuethrough various ways that are described later herein (e.g., through aclient-server “pull system” or through a client-server “push system”).

Finally, data describing compliance rules 125 with which the clientdevice 106 must comply can, for instance, specify one or more securitypolicies to which the client device 106 must adhere, a compliance status129 of the client device 106, and one or more remedial actions thatshould be performed in the event that an associated rule conditionoccurs, as described later herein. In some embodiments, the datadescribing compliance rules 125 and the data describing managementpolicies 133 is obtained from an organizational record associated withan organizational group 126 to which the client device 106 is a member(i.e., the compliance rules 125 associated with the organizational group126 are reflected in the device record of the member client device 106).

A compliance status 129 of a client device 106 represents whether thedevice is in compliance with one or more compliance rules 125. Variouscompliance rules 125 can be enforced on the client device 106 by themanagement service 116. Compliance rules 125 can be based on time,geographical location, or device and network properties. For instance,the client device 106 can satisfy a compliance rule 125 when the clientdevice 106 is located within a particular geographic location. Theclient device 106 can satisfy a compliance rule 125 in other exampleswhen the client device 106 is in communication with a particular localarea network, such as a particular local area network that is managed bythe computing environment 203. Furthermore, a compliance rule 125 inanother example can be based upon the time and date matching specifiedvalues.

A compliance rule 125 can specify that a client device 106 is requiredto be powered off or be in a low power “sleep” state during a specifiedtime period. Another compliance rule 125 can specify that a clientdevice 106 is required to be powered on or be in a normal operation“awake” state during a specified time period. As another example, acompliance rule 125 can specify that a client device 106 is prohibitedfrom rendering content that has been designated as confidential. Acompliance rule 125 can also specify whether a camera associated withthe client device 106 must be enabled or disabled. The compliance rule125 can also specify certain times of the day, week, or year in whichcertain hardware or software features are permitted to be enabled ordisabled.

Another example of a compliance rule 125 involves whether a user belongsto a particular user group. For instance, a compliance rule 125 caninclude a whitelist or a blacklist that specifies whether particularusers or groups of users are authorized to perform variousfunctionalities, such as installing or executing a particularapplication.

Other examples of compliance rules 125 include a rule that specifieswhether a client device 106 is compromised or “jailbroken.” For example,a client device 106 can have hardware or software protections in placethat prevent unauthorized modifications of the client device 106. Ifthese protections are overridden or bypassed, the client device 106 canbe considered out of compliance. As another example, a compliance rule125 can specify that the client device 106 is required to authenticate auser using a password or personal identification number (PIN) in orderto unlock the client device 106.

A compliance rule 125 can also require that the client device 106 havedevice encryption enabled, where data stored on the device is stored inan encrypted form. The data can be encrypted by a device certificate. Acompliance rule 125 can also require that the client device 106 beenrolled with the management service 116 as a managed device. Anothercompliance rule 125 can specify that the user is required to accept theterms of service that are presented by the management component 145 onthe client device 106. As another example, a compliance rule 125 canspecify that the management component 145 is required to periodicallycommunicate or “check-in” with the management service 116 to report onits status. If a threshold amount of time has elapsed since the previouscheck-in of the client device 106, the client device 106 can beconsidered to have violated this compliance rule 125.

Another compliance rule 125 can specify that a client device 106 run oneof a specified variants or versions of a particular operating system. Acompliance rule 125 can also specify that an enrolled device bemanufactured by a particular manufacturer or have a particularmanufacturer identifier. Another compliance rule 125 can specify that anenrolled device be a particular model name or model number. A clientdevice 106 can also be considered out of compliance if the device is ina data roaming mode or has used a threshold amount of a periodic networkdata usage allowance.

A compliance rule 125 can also identify a list of required applicationsthat must be installed on the client device 106 or a list of forbiddenapplications that cannot be installed on the client device 106. Themanagement component 145 can remove a forbidden application or install amissing required on application on the client device 106 in response todetecting a violation of such a compliance rule 125. A compliance rule125 can also require the presence of a mobile device management (MDM)profile, an MDM storage area, an application profile, and/or aconfiguration profile. The management component 145 can obtain and storemissing required data or containers on the client device 106 in responseto detecting a violation of such a compliance rule 125.

Therefore, the compliance status 129 indicates whether and to whatextent a particular client device 106 is compliant with compliance rules125 assigned to the client device 106 by the management service 116. Thecompliance status 129 can be determined by a management component 145 onthe client device 106 that analyzes the status of the client device 106and reports compliance to the management service 116. In other examples,the compliance status 129 can be determined by the management service116 based upon state information describing the client device 106, whichcan be reported by the management component 145. The compliance status129 can also include the state of various hardware or software featuresof the client device 106 without respect to whether the status of thefeatures are determined by a compliance rule 125.

User data 124 contains information about users who are associated withclient devices 106 that are enrolled with the management service 116.User data 124 can include profile information about a user,authentication information about a user, applications that are installedon client devices 106 associated with the user, and other userinformation. For example, user data 124 can include information aboutclient devices 106 that are associated with a user account of the user,enterprise resources to which a particular user has access, such asemail, calendar data, documents, media, applications, network sites, orother resources. The user data 124 can also identify one or more usergroups of which a particular user is a member, which can in turn definethe access rights of the user to one or more enterprise resources aswell as identify which applications should be deployed to a clientdevice 106 associated with the user. To this end, the user data 124 canfurther identify one or more device identifiers that can uniquelyidentify client devices 106 that are associated with a user account ofthe user.

The encryption keys 127 can represent one or more sets of encryptionkeys that are associated with the enterprise computing environment 103.The encryption keys 127 can include a public key that is distributed toverification devices 107 and with which a device posture token 151 canbe encrypted. The encryption keys 127 can also include a correspondingprivate key that is not distributed. The corresponding private key canbe used by the device token generator 120 to encrypt the device posturetoken 151 in which the compliance status 129 of a client device 106 isencoded.

The client device 106 can represent multiple client devices 106 coupledto the network 119. The client device 106 includes, for example, aprocessor-based computer system. According to various examples, a clientdevice 106 can be in the form of a desktop computer, a laptop computer,a personal digital assistant, a mobile phone, a smartphone, or a tabletcomputer system. The client device 106 can represent a device that isowned or issued by the enterprise to a user, or a device that is ownedby the user. The client device 106, when provisioned, can be enrolledwith the management service 116 as a managed device of the enterprise.

The client device 106 can execute a management component 145 that cancommunicate with the management service 116 to facilitate management ofthe client device 106. The management component 145 can communicate withthe management service 116 to enforce management policies and compliancerules on the client device 106. For example, the management component145 can enforce data security requirements, install, remove or updatesecurity certificates, or write, modify or delete certain data from theclient device 106. The management component 145 can also monitor theclient device 106, generate state information describing the clientdevice 106, and provide the management service 116 with such stateinformation. For example, the state information can include the networkactivity of the client device 106, the location of the client device106, whether enforce password or personal identification number (PIN)authentication is enforced, and/or whether other compliance rules 125are being complied with by the client device 106. In one example, thestate information can be generated by the management component 145 byreceiving compliance rules 125 from the management service 116 over thenetwork 119, comparing the state of the client device 106 to thecompliance rules 125, and determining whether the client device 106fails to satisfy the compliance rules 125.

To carry out local management of a client device 106, the managementcomponent 145 can be installed and executed with elevated oradministrative privileges on the client device 106. In some scenarios,the operating system of the client device 106 can allow a particularapplication or package to be identified as a device owner or a deviceadministrator, which can in turn configure the client device 106 usingsuch privileges.

The client device 106 can also execute a device token application 149.The device token application 149 can request a device posture token 151from the device token generator 120. In response, the device tokengenerator 120 can generate the device posture token 151 by assessing thecompliance status 129 of the client device 106. The device tokengenerator 120 can then provide the device posture token 151 to thedevice token application 149. The device token application 149 can thenprovide the device posture token 151 to the verification device 107,which can determine whether the client device 106 complies with thesecurity policies of an organization with which the verification device107 is affiliated.

The token generator 120 can embed some or all of the compliance status129 information associated with a requesting client device 106 into thedevice posture token 151. For example, the device posture token 151 canrepresent a data structure that identifies compliance rules 125 or otherinformation about a client device 106, such as its operating system,hardware features, software features, whether certain hardware featuresare enabled, disabled, or restricted from being enabled or disabled bythe management service 116 or the management component 145. The datastructure can be encoded into a QR code or other digital or visualrepresentation that the device token application 149 can obtain from thedevice token generator 120 and subsequently provide to the verificationdevice 107 for verification.

The device posture token 151 can also be configured to expire. Thedevice token generator 120 can embed a timestamp at which time thedevice posture token 151 is deemed to expire. The device token generator120 can also embed a timestamp representing when the device posturetoken 151 was generated as well as a lifespan of the device posturetoken 151, after which the device posture token 151 is deemed to haveexpired.

The device posture token 151 can also be configured to include acredential and/or a network-driven API command associated with themanagement service 116. As described above, the verification device 107can use the credential to authenticate to the management service 116.This may be required, as without such credential, a verification device107 is unlikely to be permitted to communicate with a management service116 that comprises a foreign management service. Once authenticated (ifrequired by the management service 116), the network-driven API commandcan be used by the verification device 107 to cause the managementservice 116 to provide the verification device 107 with one or more ofcompliance rules 125, state information describing the client device106, and an indication of whether the client device 106 complies withsuch compliance rules 125.

It is to be understood that there can be two different sets ofcompliance rules 125 with which the client device 106 must comply.First, the client device 106 can be subject to a first set of compliancerules 125 imposed by the management service 116 with which it isenrolled and by whom it is managed. That is, the client device 106 canbe subject to security policies defined by the enterprise associatedwith the client device 106 (e.g., by virtue of the user of the clientdevice 106 being an employee of the enterprise). Further, the clientdevice 106 can be subject to a second set of compliance rules 125imposed by the facility which a user of the client device 106 wishes toaccess (and within which the user wishes to possess her client device106). In one example, the first set of compliance rules 125 and thesecond set of compliance rules 125 are not identical. Accordingly, whilethe device posture token 151 can include representations of the firstset of compliance rules 125 (as the device posture token 151 can begenerated by the management service 116 associated with such first set),the device posture token 151 may not include representations of thesecond set of compliance rules 125 (as the management service 116 mayhave no knowledge of the second set). Given this, in one example, thefirst set of compliance rules 125 can be excluded from the deviceposture token 151 to optimize the process given that such first set ofcompliance rules 125 may not help determine whether the client device106 is compliant with the second set of compliance rules 125 associatedwith the facility.

Additionally, the public key associated with the private key with whichthe device posture token 151 is generated can be withheld from theclient device 106 so that the device token application 149 cannotdecrypt or modify the device posture token 151. In this way, security ofthe device posture token 151 can be ensured because the public key canbe provided only to the verification device 107. In some examples,rather than a public and private key architecture, the device posturetoken 151 can be encrypted using a pre-shared key using a symmetricencryption-decryption framework, where the key is shared between thedevice token generator 120 and the verification device 107.

The verification device 107 represents a computing device, such as abarcode scanning device, a smartphone, or a personal computer. Theverification device 107 can be coupled to a camera, a barcode scanner, anear-field communication interface, or any other communicationsinterface. The verification device 107 can also be configured with anetwork communications interface to facilitate communications over thenetwork 119. However, it is not essential for the verification device107 to have a network communications interface. The verification device107 can execute a verification application 153. The verificationapplication 153 can obtain a device posture token 151 from the clientdevice 106 over the network 119 or over another communication interface.For example, the verification application 153 can capture an encryptedform of the device posture token 151 as an alphanumeric value embeddedwithin a QR code displayed on a display of the client device 106 by thedevice token application 149.

The verification application 153 can then decrypt the device posturetoken 151 using the public key associated with the enterprise computingenvironment 103 and extract information about the compliance status 129of the client device 106. The verification application 153 can accesssecurity policies that are stored on or accessible to the verificationcomputing device 107 that specify rules that determine whether aparticular client device 107 is permitted to be carried into aparticular facility (i.e., “the second set of compliance rules 125”described above). For example, for a certain facility, client devices106 with an enabled capture sensor (e.g., camera, microphone) are notpermitted to be carried by visitors. As another example, client devices106 having a capture sensor, whether the sensor is enabled or disabled,are not permitted to be carried into the facility.

As another example, client devices 106 that have certain applicationsinstalled or client devices 106 that have been modified in some way,whether they are in or out of compliance with the compliance rules 125of the user's enterprise are not permitted to be carried into thefacility. In this way, the security policies of a particular facilityassociated with the verification computing device 107 can determinewhether the client device 106 is permitted into the facility, and evenif the device is in compliance with all of its enterprise's compliancerules 125 (i.e., “the first set of compliance rules 125” describedabove), the client device 106 can still be denied approval by theverification application 153 if the compliance status 129 indicates anystatus information that would violate the facility's security policies(i.e., “the second set of compliance rules 125” described above).Additionally, because there is a trusted computing relationship betweenthe verification device 107 and the enterprise computing environment 103(and management service 116 provided thereby), the verificationapplication 153 can trust the validity of the device posture token 151(and the contents thereof). Also, because the device posture token 151can be configured to expire, security personnel associated with afacility can be assured that the person presenting the token is notpresenting a token that was generated at a time when the client device106 did comply, as an expired token could not be used to verify that theclient device 106 currently complies. As described above, the deviceposture token 151 can also merely comprise a credential and/ornetwork-driven API command, which can further provide a technicalsolution for preventing “stale” state information or compliance statusto be relied upon as the verification device 107 can use such a deviceposture token 151 to access information describing the client device 106at the time the client device 106 last checked into or communicated withthe management service 116.

If the client device 106 complies with the security policies of anorganization, such as a government or corporate facility in which theverification device 107 is used, security personnel of such facility candetermine whether to permit a user of the client device 106 to bring theclient device 106 into the facility. The security personnel can alsodetermine whether the client device 106 must be surrendered by the userbefore entering the facility based upon the device posture token 151.

Referring next to FIG. 2, shown is an example of how the device tokenapplication 149 can request a device posture token 151 from the devicetoken generator 120. In some examples, the device token application 149can request the device posture token 151 from the management service116, as the device token generator 120 functionality can be includedwithin the management service 116. In one scenario, a user of acomputing device may enter a facility that may have security policiesgoverning whether mobile devices, tablets, or computers can be broughtinto the facility and what capabilities or compliance status of devicessuch devices must have to be permitted within the facility. Accordingly,to facilitate allowing users or guests to bring their devices into afacility or through a security checkpoint, security personnel canrequest that the user generate and present a device posture token 151.The user can present the device posture token 151 if he or she has aclient device 106 enrolled with a management service 116 that has atrust relationship with a verification device 107 operated by thesecurity personnel.

To cause such a device posture token 151 to be accessible to the clientdevice 106, the device token application 149 can request that themanagement service 116 generate the device posture token 151 andtransmit the device posture token 151 to the client device 106 in aninstance in which a button 201 within the device token application 149is activated by a user of the client device 106. The device tokenapplication 149 can also request a device posture token 151 uponlaunching of the application or can periodically request device posturetokens 151 as a background process.

Referring next to FIG. 3, in the depicted scenario, the device tokenapplication 149 has obtained a device posture token 151 from the devicetoken generator 120 and has displayed a representation of the deviceposture token 151 on the display of the client device 106. The deviceposture token 151 can be obtained as an encrypted alphanumeric string ornumeric value. The device posture token 151 can be displayed by thedevice token application 149 in a QR code or another barcode that can bevisually encoded. In some examples, the device posture token 151 can betransmitted to a verification device 107 over NFC, Wi-Fi, Bluetooth, orother network protocols and standards. As shown in FIG. 3, the deviceposture token also expires, and the device token application 149 candisplay a countdown time that indicates to the user when the deviceposture token 151 will expire.

Referring next to FIG. 4, shown is an illustration of the verificationapplication 153 executed by the verification device 107 obtaining thedevice posture token 151 from the client device 106. In this scenario,the verification device 107 can be operated by security personnelassociated with a particular facility. The verification application 153can instruct the security personnel how to obtain the device posturetoken 151 from the client device 106 of a user, such as by providinginstructions through a user interface displayed by the verificationdevice 107. In the depicted example, the device posture token 151 isobtained by capturing the QR code using a camera or barcode scannerintegrated within or in communication with the verification device 107.In some examples, the device posture token 151 can be obtained by theverification application 153 through an NFC session, a Bluetoothcommunication session, or any other network protocol or standard.

Referring next to FIG. 5, shown is an illustration of the device posturetoken 151 being obtained and validated by the verification application153 of the verification device 107. As shown in FIG. 5, once the deviceposture token 151 is obtained, the verification application 153 canverify that the device posture token 151 is authentic and determinewhether the client device 106 complies with the security policies of aparticular facility based at least in part on the information embeddedwithin the device posture token 151.

In some examples, the verification application 153 can decrypt thedevice posture token 151 using the public key installed on theverification device 107. If the data within the device posture token 151indicates that the client device 106 complies with the applicablesecurity policies, the verification application 153 can display anindication that the client device 106 (or its admittance request) isapproved. If the data within the device posture token 151 indicates thatthe client device 106 does not comply with the applicable securitypolicies, the verification application 153 can display an indicationthat the client device 106 (or its admittance request) is denied. Basedon the given result displayed by the verification application 153, thesecurity personnel of the facility can either permit the client device106 to be taken into the facility (i.e., upon an “approved” result) orcan prohibit the client device 106 from being taken into the facility(i.e., upon a “denied” result). In this way, security personnel can,without having substantial training, quickly and accurately restrictusage of incompliant client devices 106 within the facility by using theverification application 153 to screen each client device 106 seekingaccess to the facility.

Referring to FIG. 6, shown is a flowchart that provides one example ofhow the device token generator 120 can generate a device posture token151 for a client device 106. In one example, the device token generator120 can be executed by the enterprise computing environment 103 or themanagement service 116, such as in response to instructions from one ormore of the management service 116, the management component 145, or thedevice token application 149. In another example, the device tokengenerator 120 can be executed by the client device 106 or the managementcomponent 145, such as in response to instructions from one or more ofthe management service 116, the management component 145, or the devicetoken application 149.

Beginning at step 601, the device token generator 120 can obtain arequest for a device posture token 151 from a device token application149 executed by a client device 106. The request can include a deviceidentifier with which the device can be identified. At step 603, thedevice token generator 120 can extract the device identifier from therequest. At step 605, the device token generator 120 can determinewhether the requesting client device 106 is enrolled with the managementservice 116 as a managed device. If not, the process can proceed tocompletion, as the device token generator 120 cannot generate a deviceposture token 151 for a client device 106 that is not enrolled with themanagement service 116 (as administrative privileges can be required bysome operating systems to identify state information describing theclient device 106).

Otherwise, the process can proceed to step 607, where the device tokengenerator 120 can determine a compliance status 129 of the client device106. At step 609, the device token generator 120 can generate the deviceposture token 151. As noted above, the device posture token 151 can bean alphanumeric representation of the compliance status 129 of theclient device 106 and potentially other status information associatedwith the client device 106. In one example, the representation of thecompliance status 129 and other status data can include one or morekey-value pairs, where the key is an identifier of a compliance rule 125or a status variable, and the value represents the status of the clientdevice 106.

Then, at step 611, the device token generator 120 can encrypt the deviceposture token 151 using a private key corresponding to a public keyinstalled on the verification computing device 107. In one example, themanagement service 116 or management component 145 can generate a pairof a private key and corresponding public key, can cause the private keyto be stored in a memory location accessible to the device tokengenerator 120, and can cause the public key to be stored in a memorylocation accessible to the verification application 153. In anotherexample, the management service 116 or management component 145 canrequest a third-party service or library to generate the private key andcorresponding public key and request that both be provided to therequesting service or component, respectively. In such scenario, themanagement service 116 or management component 145 can thereafter causethe private key to be stored in a memory location accessible to thedevice token generator 120, and can cause the public key to be stored ina memory location accessible to the verification application 153.

Further, at step 613, the device token generator 120 can provide thedevice posture token 151 to the requesting client device 106. In oneexample, the device posture token 151 can be transmitted to the clientdevice 106 through a device management communication channel establishedbetween the management service 116 and the management component 145 ordevice token application 149. In another example, the device posturetoken 151 can be stored by the device token generator 120 in a memorylocation of the client device 106 that is accessible to the device tokenapplication 149, such as when the device token generator 120 is executedwithin the client device 106.

Referring next to FIG. 7, shown is a flowchart that provides one exampleof how the device token application 149 can obtain device posture token151 from the device token generator 120.

Beginning at step 701, the device token application 149 can generate arequest for a device posture token 151 associated with a particularclient device 106. The request can include a device identifiercorresponding to the client device 106 and be transmitted to the devicetoken generator 120. In one example, the device token application 149can cause the request to be transmitted to the management service 116 orthe management component 145 to cause such service or component togenerate a device posture token 151 associated with a particular clientdevice 106.

Next, at step 703, the device token application 149 obtains the deviceposture token 151 from the device token generator 120. In one example,the device token application 149 receives the device posture token 151from the enterprise computing environment 103 executing the device tokengenerator 120. In another example, the device token application 149receives the device posture token 151 from the management component 145executed by the client device 106. In a further example, the devicetoken application 149 obtains the device posture token 151 from a memorylocation accessible to the device token application 149 where the devicetoken generator 120 caused the device posture token 151 to be stored.

Then, at step 705, the device token application 149 can display thedevice posture token 151. As noted above, the device posture token 151can be displayed in a QR code or another visual representation of thedevice posture token 151.

Referring next to FIG. 8, shown is a flowchart that provides one exampleof how the verification application 153 can verify compliance of aclient device 106 with the security policies of a particular facilitybased upon a device posture token 151.

Beginning at step 801, the verification application 153 can obtain adevice posture token 151 from a client device 106. In one example, theverification application 153 can obtain the device posture token 151 bycapturing a QR code that the client device 106 has displayed on a userinterface of a display of the client device 106.

Next, at step 803, in the event that the device posture token 151 isencrypted, the verification application 153 can decrypt the deviceposture token 151 using the public key corresponding to the enterprisecomputing environment 103. However, if the device posture token 151 isnot encrypted, the process can proceed to step 805.

Then, at step 805, the verification application 153 can determinewhether the client device 106 complies with the security policies of aparticular facility or whether the device posture token 151 has expired.If the client device 106 does not comply with the security policies ofthe facility or if the device posture token 151 has expired based upon atimestamp or expiry timestamp embedded within the token, the process canproceed to step 807. Alternatively, if the client device 106 does complywith the security policies of the facility, the process can proceed tostep 809.

At step 807, the verification application 153 can generate a denialindication that can be displayed on a display of the verification device107 by the verification application 153. Thereafter the process canproceed to completion.

At step 809, the verification application 153 can generate an approvalindication that can be displayed on a display of the verification device107 by the verification application 153. Thereafter the process canproceed to completion.

The flowcharts of FIGS. 6-8 show examples of the functionality andoperation herein can be embodied in hardware, software, or a combinationof hardware and software. If embodied in software, each element canrepresent a module of code or a portion of code that includes programinstructions to implement the specified logical function(s). The programinstructions can be embodied in the form of source code that includeshuman-readable statements written in a programming language or machinecode that includes machine instructions recognizable by a suitableexecution system, such as a processor in a computer system or othersystem. If embodied in hardware, each element can represent a circuit ora number of interconnected circuits that implement the specified logicalfunction(s).

Although the flowcharts of FIGS. 6-8 show a specific order of execution,it is understood that the order of execution can differ from that whichis shown. The order of execution of two or more elements can be switchedrelative to the order shown. Also, two or more elements shown insuccession can be executed concurrently or with partial concurrence.Further, in some examples, one or more of the elements shown in theflowcharts can be skipped or omitted. In addition, any number ofcounters, state variables, warning semaphores, or messages could beadded to the logical flow described herein, for purposes of enhancedutility, accounting, performance measurement, or troubleshooting aid. Itis understood that all such variations are within the scope of thepresent disclosure.

The client device 106, enterprise computing environment 103, or othercomponents described herein, can each include at least one processingcircuit. The processing circuit can include one or more processors andone or more storage devices that are coupled to a local interface. Thelocal interface can include a data bus with an accompanyingaddress/control bus or any other suitable bus structure. The one or morestorage devices for a processing circuit can store data or componentsthat are executable by the one or processors of the processing circuit.Also, a data store can be stored in the one or more storage devices.

The management service 116, device token generator 120, device tokenapplication 149, verification application 153, and other componentsdescribed herein can be embodied in the form of hardware, as softwarecomponents that are executable by hardware, or as a combination ofsoftware and hardware. If embodied as hardware, the components describedherein can be implemented as a circuit or state machine that employs anysuitable hardware technology. The hardware technology can include one ormore microprocessors, discrete logic circuits having logic gates forimplementing various logic functions upon an application of one or moredata signals, application specific integrated circuits (ASICs) havingappropriate logic gates, programmable logic devices (e.g.,field-programmable gate array (FPGAs), and complex programmable logicdevices (CPLDs)).

Also, one or more or more of the components described herein thatincludes software or program instructions can be embodied in anynon-transitory computer-readable medium for use by or in connection withan instruction execution system such as a processor in a computer systemor other system. The computer-readable medium can contain, store, ormaintain the software or program instructions for use by or inconnection with the instruction execution system.

The computer-readable medium can include physical media, such as,magnetic, optical, semiconductor, or other suitable media. Examples of asuitable computer-readable media include, but are not limited to,solid-state drives, magnetic drives, flash memory. Further, any logic orcomponent described herein can be implemented and structured in avariety of ways. One or more components described can be implemented asmodules or components of a single application. Further, one or morecomponents described herein can be executed in one computing device orby using multiple computing devices.

It is emphasized that the above-described examples of the presentdisclosure are merely examples of implementations to set forth for aclear understanding of the principles of the disclosure. Many variationsand modifications can be made to the above-described examples withoutdeparting substantially from the spirit and principles of thedisclosure. All of these modifications and variations are intended to beincluded herein within the scope of this disclosure.

We claim the following:
 1. A system for generating a device posturetoken, comprising: at least one computing device comprising a processorand a memory; and a device token generator executable by the at leastone computing device, the device token generator causing the at leastone computing device to at least: obtain a request for a device posturetoken associated with a client device; determine a device compliancestatus associated with the client device, the device compliance statusindicating compliance with a plurality of compliance rules specified bya management service executed remotely from the client device; generatethe device posture token, wherein the device compliance status isembedded within the device posture token; encrypt the device posturetoken using a private key that is withheld from the client device; causethe encrypted device posture token to be accessible to the clientdevice.
 2. The system of claim 1, wherein the device posture tokencomprises an alphanumeric value embedded in a quick-response codedisplayed by the client device.
 3. The system of claim 1, wherein thedevice posture token comprises a representation of the device compliancestatus of the client device, the representation of the device compliancestatus identifying whether the client device complies with a pluralityof compliance rules associated with the client device.
 4. The system ofclaim 1, wherein the device posture token comprises an identity ofapplications installed on the client device or an indication of whethera hardware feature or software feature has been enabled or disabled onthe client device.
 5. The system of claim 1, wherein the device posturetoken is encrypted with a private key associated with the device tokengenerator.
 6. The system of claim 5, wherein a trust relationship isestablished between a verification computing device and the at least onecomputing device by causing a public key corresponding to the privatekey to be accessible to the verification computing device.
 7. The systemof claim 6, wherein a verification computing device is configured todecrypt the device posture token using the public key corresponding tothe private key.
 8. A method for generating a device posture token,comprising: obtaining a request for a device posture token associatedwith a client device; determining a device compliance status associatedwith the client device, the device compliance status indicatingcompliance with a plurality of compliance rules specified by amanagement service executed remotely from the client device; generatingthe device posture token, wherein the device compliance status isembedded within the device posture token; encrypting the device posturetoken using a private key that is withheld from the client device; andcausing the encrypted device posture token to be accessible to theclient device.
 9. The method of claim 8, wherein the device posturetoken comprises an alphanumeric value embedded in a quick-response codedisplayed by the client device.
 10. The method of claim 8, wherein thedevice posture token comprises a representation of the device compliancestatus of the client device, the representation of the device compliancestatus identifying whether the client device complies with a pluralityof compliance rules associated with the client device.
 11. The method ofclaim 8, wherein the device posture token comprises an identity ofapplications installed on the client device or an indication of whethera hardware feature or software feature has been enabled or disabled onthe client device.
 12. The method of claim 8, wherein the device posturetoken is encrypted with a private key associated with a device tokengenerator configured to generate the device posture token.
 13. Themethod of claim 12, wherein a trust relationship is established with averification computing device by causing a public key corresponding tothe private key to be accessible to the verification computing device.14. The method of claim 13, wherein a verification computing device isconfigured to decrypt the device posture token using the public keycorresponding to the private key.
 15. A non-transitory computer-readablemedium comprising machine-readable instructions for generating a deviceposture token, wherein when executed by a processor of at least onecomputing device, the machine-readable instructions cause the at leastone computing device to at least: obtain a request for a device posturetoken associated with a client device; determine a device compliancestatus associated with the client device, the device compliance statusindicating compliance with a plurality of compliance rules specified bya management service executed remotely from the client device; generatethe device posture token, wherein the device compliance status isembedded within the device posture token; encrypt the device posturetoken using a private key that is withheld from the client device; andcause the encrypted device posture token to be accessible to the clientdevice.
 16. The non-transitory computer-readable medium of claim 15,wherein the device posture token comprises an alphanumeric valueembedded in a quick-response code displayed by the client device. 17.The non-transitory computer-readable medium of claim 15, wherein thedevice posture token comprises a representation of the device compliancestatus of the client device, the representation of the device compliancestatus identifying whether the client device complies with a pluralityof compliance rules associated with the client device.
 18. Thenon-transitory computer-readable medium of claim 15, wherein the deviceposture token comprises an identity of applications installed on theclient device or an indication of whether a hardware feature or softwarefeature has been enabled or disabled on the client device.
 19. Thenon-transitory computer-readable medium of claim 15, wherein the deviceposture token is encrypted with a private key associated with themanagement service.
 20. The non-transitory computer-readable medium ofclaim 19, wherein a verification computing device is configured todecrypt the device posture token using a public key corresponding to theprivate key.